The test of a software application is a very critical phase of its development. This is especially true for the detection of lock conditions (or simply locks) in a software application of the non-sequential type, wherein multiple application units (such as threads) can be executed concurrently in a non-deterministic order. A classical situation is that of a deadlock, wherein two threads are unable to proceed because each one of them is waiting for something to be done by the other. For example, the deadlock may occur when a first thread is waiting for a variable that has already been locked by a second thread, and at the same time the second thread is waiting for another variable that has already been locked by the first thread. Several tools are available to facilitate the identification of potential deadlocks during the development of the software application. These tools may be based on either a static analysis of the software application (on the basis of its definition) or a dynamic analysis thereof (on the basis of its execution).
Other deadlocks may occur in a software application of the transactional type. In this case, the software application interacts with a database (i.e., a structured collection of data) in coherent, reliable, and atomic interaction units—sometimes referred to as transactions—through a corresponding Database Management System (DBMS). A typical example is that of two transactions, each one formed by a pair of queries that race for an exclusive access to different elements of the database.
The DBMS is generally able to detect the occurrence of the transaction deadlocks at run-time. When this happens, the DBMS cancels one or more of the involved transactions, and rolls back the database to restore its (correct) status preceding the canceled transactions.